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Abstract 

Trusted computing (e.g. TCPA and Microsoft's Next- 
Generation Secure Computing Base) has been one of the 
most talked about and least understood technologies in 
the computing community over the past year. The ca- 
pabilities trusted computing provides have the potential 
to radically improve the security and robustness of dis- 
tributed systems. Unfortunately, the debate over its ap- 
plication to digital rights management has caused its sig- 
nificant other applications to be largely overlooked. In 
this paper we present a broader vision for trusted com- 
puting. We give an intuitive model for understanding the 
capabilities and limitations of the mechanisms provided 
by trusted computing. We describe a flexible OS archi- 
tecture to support trusted computing. We present a range 
of practical applications that illustrate how trusted com- 
puting can be used to improve security and robustness in 
distributed systems. 



1 Introduction 

Many difficult problems in today's distributed systems, 
such as preventing denial of service, performing access 
control and monitoring, and achieving scalability, are 
either caused or severely exacerbated by the fact that 
clients are untrusted and thus potentially malicious. This 
forces system designers to implement most system pol- 
icy and sensitive computations in the core of the system, 
where trust resides, instead of at the endpoints where 
most of the system's resources and capabilities are. The 
only complete solution to this problem has been the vise 
of closed platforms, such as those in cellular networks 
and banking systems, where special-purpose, tamper- 
resistant clients are utilized that provide end-to-end trust. 
This approach has demonstrated significant benefits, al- 
lowing the construction of some of today's most capable 
and robust distributed systems. Unfortunately, this ap- 
proach presently necessitates the use of dedicated hard- 
ware, thus limiting designers to the use of only a few 
types of devices over which they must have exclusive 
control. 



In the near future it will no longer be necessary to force 
designers to make trade-offs between the benefits of open 
and closed platforms. This change will come as the re- 
sult of ubiquitous support for trusted computing plat- 
forms. Trusted platforms will allow systems to extend 
trust to clients running on these platforms, thus provid- 
ing the benefits of open platforms: wide availability, di- 
verse hardware types, and the ability to run many ap- 
plications from many mutually distrusting sources while 
still retaining trust in clients. 

The vision of trusted platforms cannot be achieved with 
today's operating systems which offer poor assurance 
and implement a security model that is largely orthog- 
onal to that required for trusted computing. To meet the 
demands of implementing a trusted platform we outline 
the design of a new OS architecture based on the idea of 
a trusted virtual machine monitor. In this model, tradi- 
tional applications and OSes can run side-by-side on the 
same platform in either an "open box" or "closed box" 
execution model in keeping with the trust requirements 
imposed by the application. 

In the next section we define and describe the compo- 
nents that make up trusted computing. In Section 3 we 
present our approach of using a trusted virtual machine 
monitor to support a mixture of open and closed box 
models simultaneously. In Section 4 we examine a se- 
lection of practical areas where trusted computing can 
provide novel functionality yielding significant benefits 
for security, scalabifity and robustness. Section 5 dis- 
cusses related work. 



2 Trusted Platforms 

Open platforms are general-purpose computing plat- 
forms where there is no apriori trust established between 
the hardware of the platform and a third party, that could 
be used to prove the functionality of the platform. Exam- 
ples of these include workstations, mainframes, PDAs, 
and PCs. Open platforms possess many practical bene- 
fits over closed platforms. Unfortunately a remote party 
cannot make any assumptions about how that platform 



will behave or misbehave. 

Closed platforms are special-purpose computing devices 
that interact with the user via a restricted interface 
(e.g. automated tellers, game consoles, and satellite re- 
ceivers). A closed platform can authenticate itself as an 
authorized platform to a remote party using a secret key 
embedded in the platform during manufacturing. Closed 
platforms rely on hardware tamper resistance to protect 
the embedded secret key and ensure well-behaved oper- 
ation. 

Trusted platforms provide the best properties of open and 
closed platforms. As with an open platform, trusted plat- 
forms allow applications from many different sources to 
run on the same platform. As with a closed platform, 
remote parties can determine what software is running 
on a platform and thus determine whether to expect the 
platform to be well behaved. The process of dynami- 
cally establishing that a platform conforms to the spec- 
ification expected by a remote party is done through a 
process called attestation. 

Attestation consists of several steps of cryptographic au- 
thentication by which the specification for each layer of 
the platform is checked from the hardwaie up to the op- 
erating system and appHcation code. At a high level, the 
steps in a basic model of attestation are as follows. A 
more detailed example is given in Section 4: 

• A hardware platform has a signing key Ksign- It 
also has a public key certificate (Chw) for this key. 

• When an application A is started it first generates a 

public/private key pair PKa/SKa- Next, the ap- 
pHcation requests the platform to certify its pubHc 
key PKa- The platform uses its signing key Ksign 
to generate a certificate for PKa- We denote this 
certificate by Ca- Along with standard certificate 
fields, the certificate Ca contains the hash of the ex- 
ecutable image of the application A. This hash is 
at the heart of the attestation process. The signed 
certificate Ca is returned to the application. 

• When the application A wants to attest its valid- 
ity to a remote server it sends the certificate chain 
{Chtv , Ca) to the remote server. The server checks 
two things: 

- The signatures on both certificates are vafid 
and Ch^ is not revoked, and 

- The application hash embedded in Ca is on 
the server's list of applications it trusts. 

At this point the server is assured that Ca comes 
from an application it trusts. The application can 
now authenticate itself by proving knowledge of 
SKa ■ For example, the application and the remote 
server could run an authenticated key exchange to 
generate a shared session key. All communication 



between the remote server and the application will 
be protected using this key. 

We emphasize that attestation must result in a shared se- 
cret between the application and remote party, otherwise 
the platform is vulnerable to session hijacking — an at- 
tacker could wait for attestation to complete, reboot the 
machine into untrusted mode, and masquerade as an au- 
thorized application. 

Leveraging attestation requires the presence of software 
that allows the remote party to meaningfully interpret the 
state of the system. This takes place through a multi-step 
process whereby the hardware will attest to what oper- 
ating system it booted, the operating system will in turn 
attest what appHcation it requires a key for, and wiU only 
aUow the use of that key by that given application. 

Limitations of attestation. It is important to realize 
that software attestation only tells a remote party exactly 
what executable code was launched on a platform and 
establishes a session key for future interaction with that 
software component on the platform. This does not pro- 
vide trustworthiness in the usual sense: 

• The software component could be buggy and pro- 
duce incoiTect results. The onus is on the remote 
party to choose who to trust. 

• Attestation provides no information about the cur- 
rent state of the running system. For example, at- 
testation does not show whether the software com- 
ponent has been compromised by a buffer overflow 
attack, infected by a virus, etc. 

• Future behavior can only be ensured for authenti- 
cated interactions via a shared secret. 

• A platform is only as trusted as the tamper re- 
sistance of hardware and level of assurance of its 
trusted OS. 



3 An OS for Trusted Platforms 

The vision of trusted computing falls apart when it en- 
counters the realities of modern general-purpose oper- 
ating systems. OSes such as Microsoft Windows and 
Linux are large and complex code bases optimized over 
the years for ease of use, performance, and reliability. As 
a result they are incompatible both in design and imple- 
mentation with the objective of providing a high assur- 
ance platform. High assurance is essential as a trusted 
OS must instill confidence in remote parties that it can 
be relied upon to execute their code in a well-specified 
fashion. 



The protection model provided by contemporary oper- 
ating systems is poorly matched to the needs of trusted 
computing. In a trusted platform the primary security 
objective is to isolate subjects from one another. The 
fine-grained resource abstractions for controlled sharing 
provided by typical OSes would add needless complex- 
ity to a trusted OS, thus detracting from its primary goal 
of providing secure isolation. 

The approach we advocate and have begun to explore 
in our own work on building a trusted operating system, 
is to use a virtual machine monitor [14] (VMM). A vir- 
tual machine monitor is a thin system software layer that 
exports the abstractions of virtual machines (VMs) that 
look like the real hardware. 

The simplicity of the VMMs interface and implementa- 
tion provides the means for building a high-assurance 
OS that offers strong isolation [17]. VMM's also pro- 
vide backwards compatibility, allowing existing services 
and operating systems to realize the benefits provided by 
tnisted platforms with little or no modification. Users 
can continue to use their normal operating systems for 
applications that do not require trust from a remote party. 
Developers building services that require trust can utilize 
the wide range of existing secure operating systems, ap- 
plications, etc. , thus allowing them to leverage a huge 
amount of high quality existing code and development 
environments. 

Our trusted virtual machine monitor (T-VMM) exports 
two different types of virtual machine abstractions: 

Open-box VMs are traditional virtual machines that ex- 
actly match the hardware interface of the machine. They 
are used to run general -purpose operating systems such 
as Microsoft Windows or Linux and allow the platform 
owner full access to the hardware state of the VM just as 
in a normal open platform. 

Closed-box VMs provide the same hardware interface as 
open-box VMs. In addition, a virtual device is provided 
that allows them to do attestation. To platform owners, 
the closed-box VMM is a black box. They can grant 
it access to resources but they cannot inspect or tamper 
with its contents. 

Hardware attestation needs only attest to the fact that the 
T-VMM is running. For applications to attest, the attes- 
tation virtual device can provide a closed-box VM with a 
signed hash of its executable plus some attributes which 
it can then present to a remote party to obtain a token 
encrypted under the public key of the T-VMM. The at- 
testation interface can then be used to decrypt this token, 
but it will only release the token to the VM whose hash 
and attributes match those that were originally used to 
request the token. This token will contain a session key, 
certificate, or some other means of allowing the VM to 



authenticate itself. 

The T-VMM has total control of both the visibility and 
use of hardware resources by the VMs. Resource man- 
agement policy is specified by the platform owner di- 
rectly to the T-VIVLM. 

Storage devices are abstracted into disjoint virtual disks. 
Virtvial storage can be either encrypted at the block level 
by the T-VMM or left as plain text in accordance with the 
performance and security requirements of the VM. Com- 
munication devices such as network interface cards can 
either be virtualized or exported directly to a VM. User 
interface and display devices are multiplexed among the 
VMs in such a fashion that one VM cannot observe the 
user interactions of another. 

To support composition of VMs and communicate be- 
tween VMs, the T-VMM supports the notion of a virtual 
device. A virtual device can be implemented by a closed 
box VM and exported as a device to any VM. For exam- 
ple, many closed box VMs will want to export a virtual 
NIC or virtual serial port to allow other local VMs access 
to their functionality. 

The T-VMM supports a trusted console that allows ac- 
cess to the T-VMM. This is used to control the allocat- 
ing hardware sources to VMs, mapping of I/O devices to 
VMs, the destruction of VMs, etc. . The console VM can 
be accessed via a trusted path. How to securely facilitate 
this access in a backwards compatible and seamless way 
is a question we are still are working to address. 



4 Example Applications 

We survey several areas where trvisted platfomis promise 
to have significant impact. We discuss how the introduc- 
tion of trusted platforms can significantly increase the 
functionality of existing client side technologies, such 
as distributed firewalls and massively distributed paral- 
lel computing clients. We also look at some entirely 
novel applications of this technology, like those facili- 
tated by rate limiting. We do not discuss any applications 
related to Digital Rights Management (DRM) since we 
find them far less exciting that the applications discussed 
below. 

Regulated Endpoints and Distributed Firewalls. Tra- 
ditionally firewalls assume that everyone on the "inside" 
of the network is trusted, while everyone on the outside 

is untrusted. However, the increased use of wireless ac- 
cess points, tunnels, VPNs, and dial-ins breaks down the 
distinction between inside and outside. Given today's in- 
creasingly dynamic network topologies, distributed fire- 
walls [7] greatly simplify the task of implementing net- 
work security policies. With a distributed firewall secu- 



rity policy is defined centrally, but enforced at each in- 
dividual network endpoint. This supports a richer set of 
policies and greater scalability than traditional central- 
ized firewalls [15]. 

On standard hosts, distributed firewalls do an excellent 
job of protecting a host fi*om others, but are of little use 
for protecting others from the host — there is no way of 
ensuring that the host does not simply tamper with or 
bypass the firewall. 

On a trusted platform a distributed firewall is a sig- 
nificantly more powerful primitive since it can prevent 
packets that violate the central security policy from ever 
reaching the network in the first place. For example, the 
distributed firewall can prevent applications that attempt 
port scanning and IP spoofing from ever reaching the net- 
work. Similarly, the firewall can ensure that all VMs on 
the machine are properly implementing connection rate 
limits. Hence, distributed firewalls on trusted platforms 
can provide well-regulated endpoints for a wide variety 
of different network types. 

The architecture for a distributed firewall on a trusted 
platform is as follows. The distributed firewall runs in 
its own closed-box VM and listens on a virtual NIC. All 
packets generated by open-box appHcation VM's on the 
machine are sent to the distributed firewall VM. The dis- 
tributed firewall ensures that these packets adhere to the 
security policy being enforced. If so, it embeds them into 
an IPsec packet and sends them to their destination on the 
network. If not, the packets are blocked. The termination 
point of the IPsec tunnel is the closest network gateway, 
or alternatively, the remote destination host. The IPsec 
tunnel is only used to prove to the IPsec endpoint de- 
vice that the packets are sent via the firewall VM. Con- 
sequently, it suffices to use the Authentication Header 
(AH) in IPsec. There is no need to encrypt the packets. 

The main question is how does the IPsec endpoint de- 
vice know that the sending host is running a distributed 
firewall. At a high level, the idea is as follows: during 
initial firewall setup the distributed firewall VM uses at- 
testation to convince a certification authority (CA) that it 
is an authorized firewall implementing the required secu- 
rity poHcy. The CA issues a certificate to the firewall VM 
enabling it to establish IPsec tunnels with peer devices. 
Without this certificate, peer devices will reject connec- 
tion requests. Consequently, no application on the ma- 
chine can communicate with a networked device unless 
it sends its packets through the firewall VM. 

In reality, the exact firewall VM architecture is more 
complicated. We briefly explain the initial attestation 
protocol with the CA. We are assuming that the T- 
VMM on the machine has certified public/private key 
pairs that can be used for encryption/decryption and for 



signing. The following steps take place during initial 
firewall setup: 

• the firewall VM generates a public/private key pair 

• The firewall VM requests the T-VMM to sign the 
hash of the executable image running inside the fire- 
wall VM. Let S be the resulting signature. This 
signature is the main capability used for attestation. 

• The firewall VM contacts a CA and sends the pub- 
lic key PKpw^ the signature S, and a certified T- 
VMM public key PKvmm- 

• The CA verifies that the firewall executable im- 
age (whose signature is S) is an authorized fire- 
wall. If so, it issues a certificate CERTpw for 
the firewall's public key PKpw The CA also em- 
beds the hash of the firewall executable in the cer- 
tificate. The CA encrypts the resulting certificate 
CERTpw under PKvmm and sends the resulting 
ciphertext E[CERTfw] to the firewall. 

This completes the initial firewall setup. Note that no 
open-box VM can directly use E[CERTfw] since it is 
encrypted using the T-VMM' s public key. Whenever the 
firewall VM is launched, it first requests the T-VMM 's 
virtual attestation device to decrypt E[CERTfw]- The 
T-VMM does so only if the hash of the executable run- 
ning in the VM matches the hash inside CERTpw ■ If 
there is a match, the firewall VM obtains CERTpw 
which enables it to setup IPsec tunnels with remote hosts. 
Consequently, when a remote host receives an IPsec ses- 
sion request using CERTpw it is assured that the re- 
questing machine is running an authorized firewall VM. 

Rate Limiting for DDOS Prevention. Rate limiting 

can be used to address the problem of Distributed De- 
nial of Service (DDOS) attacks at both the network and 
application levels. For example, by limiting the rate at 
which client machines can issue queries in a P2P net- 
work we defend against certain P2P DoS attacks [9]. By 
Umiting the rate at which a machine can open network 
connection we defend against certain network DDOS at- 
tacks [16, 10]. Finally, by limiting the rate at which ma- 
chines can send email we reduce the rate at which spam 
email is generated [11]. 

Implementing a rate limiter with a trusted platform is 
straightforward. On each trusted platform we run a 
ticket-granting service in a closed-box VM. The ticket- 
granting service issues at most one ticket every time 
quantum. These tickets are content dependent. For ex- 
ample, to limit the rate at which a P2P client issues 
queries we require an open-box P2P client VM to ob- 
tain a ticket from a ticket- granting VM for every query 
being sent. More precisely, prior to issuing a query, the 
P2P client VM sends a hash of the query to the ticket- 



granting VM (via a virtual NIC). The resulting ticket is 
attached to the outgoing query. The P2P network will 
discard any incoming queries that contain no ticket or 
an invalid ticket. Consequently, each client machine can 
generate at most one query every time quantum (say ev- 
ery 5 seconds). 

Without attestation the best known method for achieving 
these types of rate limits is using client puzzles [11, 4], 
the practice of forcing a client to perform some costly 
computation (solving a puzzle) for each request made. 
A trusted computing solution has several major advan- 
tages over cUent puzzles: no resources must be wasted in 
order to generate tickets (a real consideration on mobile 
devices where computing expensive client puzzles could 
present a significant power drain); users do not need to 
wait for tickets to be issued; client puzzles vary heavily in 
their impact based on the type of platform (processor and 
memory speeds, etc.) whereas trusted-computing based 
rate limiters are independent of device size or Moore's 
law. 

Improving Robustness via Reputation. Understanding 
DDOS attacks on today's P2P storage systems requires 
considering a broad spectrum of attack types. One of the 
most insidious types of attacks are those based on con- 
tent poisoning, where a user disseminates damaged or 
incomplete content (e.g. audio files which have artifacts 
inserted) in order to make the good content difficult or 
impossible to find amongst the noise. 

One approach to solving these and other problems of 
mis -behaving users are the use of reputation systems. 
These are already widely seen in use in online games, 
P2P file sharing systems [2], and even on eBay to ensure 
the integrity of sellers. One difficulty with reputation 
systems is that when users misbehave and their identity is 
tarnished they can simply apply for a new identity. With- 
out extra infrastructure there is no way to tell whether 
two distinct identities represent the same entity. 

Trusted platforms provide an ideal means of building 
more robust reputation systems. First, using trusted plat- 
forms we can ensure that a single hardware platform 
represents at most one identity. Consequently, to reg- 
ister multiple identities in a single system one would 
have to purchase multiple hardware platforms. This ap- 
proach would thwart common attacks on reputation sys- 
tem where a single platform registers thousands of ma- 
licious identities. Second, trusted platforms simplify de- 
centralized reputation systems since the platform can be 
used to track its own reputation. 

Third-Party Computing. Increasingly computing re- 
sources are being borrowed, leased, or donated by a third 
party. Examples of this include (1) using donated cy- 
cles for massively parallel scientific and mathematical 



computations by distributed.net, SETI@home, and Fold- 
ing @home, (2) using leased time on commercial com- 
puter farms for doing large-scale rendering and anima- 
tion, and (3) the emerging field of grid computing that 
allows heavy users of scientific computing resources to 
pool and share their computing resources. 

The difficulty with this approach to massively parallel 
computation is trusting the machines doing the compu- 
tation to (1) produce the correct results, and (2) keep the 
contents of the computation secret. Trusted platforms of- 
fer an ideal mechanism for solving both problems. Using 
attestation, remote machines can prove that they are run- 
ning the expected executable image, the trusted OS will 
of course keep the computation and its associated state 
private. The executable can use its token to sign and 
encrypt the results of its computation, thus ensuring its 
privacy and authenticity. 

Civil Liberties Protection. Increasingly law enforce- 
ment requires the use of network surveillance devices [1] 
that can potentially infringe on civil liberties. Cur- 
rently, these devices are certified not to exceed their le- 
gal boundaries by inviting a select group of experts to 
review their design. However, there is no guarantee that 
the system reviewed by the experts is the one deployed 
in the field. Attestation enables us to do precisely that. 
Building such devices on a trusted platform enables the 
platform to prove to third parties that the software on 
the device is the one authorized to execute. Note that 
our threat model excludes compromise of the underlying 
tamper-resistant hardware, which is possibly not beyond 
the reach of law enforcement agencies. 



5 Related Work 

The basic mechanisms of attestation have been well stud- 
ied. Gasser et al. [13] describes an architecture which 
performs a secure loading process with minimal hard- 
ware support to certify to a remote party the operating 
systems and applications on a platform. Work by Tygar 
et al. [18] describes host integrity checking with secure 
coprocessor. More recent work by Arbaugh [6] presents 
a practical architecture for secure bootstrapping that pro- 
vides a similar chain of integrity checks to those required 
for attestation. However, it is important to note that 
secure bootstrapping and attestation are fundamentally 
different capabihties. Secure bootstrapping limits what 
software can be run on a platform, whereas attestation 
merely reports what software a platform is running. 

Prior work has studied attestation in a relatively lim- 
ited context, usually allowing hosts within an admin- 
istrative domain to certify what OS they are running 



to their peers or an administrator [19]. Our much 
broader vision of trusted computing coincides with ef- 
forts such as TCPA [5] and Microsoft's Next Genera- 
tion Secure Computing Base (NGSCB) project (formerly 
"Palladium") [8, 3] to deploy trusted computing plat- 
forms ubiquitously and provide a very general mecha- 
nism for application designers. 

TCPA is a platform specification developed by an indus- 
try consortium to provide hardware support for trusted 
computing. Several current implementations of the ini- 
tial TCPA 1.1b spec have already been implemented in 
single chips and shipped in the IBM T30 laptops. TCPA 
does not provide a complete solution to building a trusted 
platform as it deals strictly with the problem of key man- 
agement and attestation. Other features required to sup- 
port a flexible trusted OS (e.g. efficient architecture sup- 
port for virtualization, additional protection mechanisms, 
a trusted path to the trusted OS, etc.) are not provided by 
TCPA. The software model assumed by TCPA is implic- 
itly one of a trusted version of today's commodity OS's. 
As we have argued this approach is incompatible with 
the assurance requirements of a trusted platform. 

Microsoft's NGSCB project aims to provide hard- 
ware [12] and OS support for running authenticated soft- 
ware on an open platform. In NGSCB trusted applica- 
tions are built on top of a single dedicated trusted oper- 
ating system specified by Microsoft. This operating sys- 
tem is protected from Windows (but not vice- versa) via 
special purpose hardware memory protection. All appli- 
cations are Hmited to using only this common operating 
system. In short, NGSCB as it is currently described pro- 
vides less flexibility and weaker isolation properties than 
our proposed architecture. 



6 Conclusion 

We have just begun to explore the broad range of po- 
tential benefits that trusted computing can bring to dis- 
tributed systems. Extending trust from the core of the 
network to its end-points solves or greatly simphfies 
many problems in distributed systems as well as enabling 
a wide range of new applications. In future work we will 
continue to study the range of systems issues that arise in 
implementing OS support for trusted computing as well 
as engage in further study of its applications. 
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